In Cozystack, the Package resources (including cozystack.cozystack-platform) are typically located in the cozy-system namespace. Running kubectl patch without specifying the namespace will fail if the user's current context is set to another namespace (like default). Adding -n cozy-system ensures the command runs successfully.

The Package resource needs to be created in the cozy-system namespace for the Cozystack operator to detect and reconcile it. Adding namespace: cozy-system to the metadata ensures it is applied to the correct namespace.

⚠️ This HAMi claim is incorrect and would lead users into a resource conflict.

• "HAMi reuses the same device plugin layer" is wrong. HAMi ships its own device plugin + scheduler extender. The page you link to states the opposite: "When HAMi is enabled, GPU Operator's built-in device plugin is automatically disabled to avoid resource registration conflicts."
• That auto-disable only lives in the tenant kubernetes app chart (packages/apps/kubernetes/tests/gpu_operator_hami_test.yaml — "should disable devicePlugin when hami is enabled"). The management-cluster cozystack.hami PackageSource only declares dependsOn: cozystack.gpu-operator (install ordering); packages/system/hami/values.yaml does not touch the operator's device plugin.
• The container variant pins devicePlugin.enabled: true (values-container.yaml in #2766). Stacking cozystack.hami on top, as written, runs two device plugins both registering nvidia.com/gpu — exactly the conflict the HAMi doc warns about.

Suggested rewrite:

The `container` variant exposes whole GPUs through the upstream NVIDIA device plugin.
For fractional sharing (per-pod memory and compute quotas), see
[GPU Sharing with HAMi](/docs/next/kubernetes/gpu-sharing/) — currently documented for
tenant Kubernetes clusters, where enabling HAMi automatically disables the GPU Operator's
built-in device plugin to avoid resource-registration conflicts. Stacking the
`cozystack.hami` package directly on top of the `container` variant on the management
cluster is not a supported combination yet: the variant pins the NVIDIA device plugin on,
and running it alongside HAMi's device plugin causes both to register `nvidia.com/gpu`.

The intro at line 10 ("you can stack HAMi on top once the container variant is up") echoes the same claim and should be softened to match.

The companion PR's own OS-support table (docs/gpu-vgpu.md in #2766) only covers Ubuntu 20.04–26.04 and Talos. Cozystack's documented node-OS surface is Talos + Ubuntu/Debian (ansible path). Listing RHEL/Fedora/openSUSE as "supported" presents untested territory as fact.

- The GPU node runs Ubuntu or Debian with the NVIDIA driver installed via the distro
  package manager (other distros with an equivalent driver + toolkit package layout
  should work the same way but are not regularly tested). Verify with `nvidia-smi` …

apt install nvidia-container-toolkit alone does not modify containerd config — registration is a separate manual step. A reader on a fresh node will fail this grep with no pointer to the fix. Suggest spelling out the registration:

- `nvidia-container-toolkit` installed on the same node and registered with containerd:

  ```bash
  sudo nvidia-ctk runtime configure --runtime=containerd
  sudo systemctl restart containerd
  grep nvidia /etc/containerd/config.toml   # must show the runtime entry

Run back-to-back, kubectl logs errors while the (large) CUDA base image is still pulling. Add a wait:

kubectl apply -f cuda-smoke.yaml
kubectl wait --for=jsonpath='{.status.phase}'=Succeeded pod/cuda-smoke --timeout=5m
kubectl logs cuda-smoke

Minor gotcha worth one prerequisite line: the container variant relies on the upstream default workload container for unlabeled nodes. A node still carrying nvidia.com/gpu.workload.config=vm-passthrough from the GPU Passthrough guide overrides that per-node and the device plugin won't serve it — a likely trip-up when migrating a node off the passthrough setup.

- The GPU node must not carry a `nvidia.com/gpu.workload.config` label left over from the
  passthrough setup (`kubectl label node <node-name> nvidia.com/gpu.workload.config-` to remove).

The stated reason here is incorrect, though the practical advice is right. gpu-operator in the iaas bundle does not go through the cozystack.platform.package.optional.default helper and does not hardcode spec.variant: default. iaas.yaml renders it via cozystack.platform.package with $gpuVariant = bundles.iaas.gpuOperatorVariant | default "default", and immediately fails the Helm render if that value is anything other than "default" or "vgpu":

{{- if not (or (eq $gpuVariant "default") (eq $gpuVariant "vgpu")) -}}
{{- fail (printf "bundles.iaas.gpuOperatorVariant must be \"default\" or \"vgpu\", got %q" $gpuVariant) -}}
{{- end -}}

So "container" via the bundle path causes a hard Helm render failure, not a silent overwrite — the user Package CR is never touched because the chart never renders. Suggested replacement:

Do not add cozystack.gpu-operator to bundles.enabledPackages for this variant. The iaas bundle template only accepts bundles.iaas.gpuOperatorVariant: default or vgpu; any other value — including container — causes a hard Helm render failure (packages/core/platform/templates/bundles/iaas.yaml). Apply the Package CR directly instead; the platform controller installs it without a bundle entry and without the variant restriction.